I'm ok with raising an exception here, I'm not sure about UndefinedFunctionError though.

Here's the reasons I'm less inclined to use UndefinedFunctionError:

1. It's not very descriptive to the situation. The changeset here handles the case that Patch.Mock.module/1 returns an error, the thing that's undefined is actually the module not the function.
2. Well, you may retort, if the module is missing then so is the function. I agree with this but the implementation will happily no-op on a missing function.

This leaves us in a situation where the only time patch raises an UndefinedFunctionError is when the module is undefined and not when the function is undefined which also seems like weird behavior.

I think it would make sense to do either of the following:

1. Introduce a custom error here which more clearly indicates the failure. UndefinedModuleError. Use that for this case and retain the current behavior of no-op on a missing function.
2. Change the behavior on missing function to raise and then this can remain UndefinedFunctionError.

Are you interested in either of those alternatives?

I completely agree that UndefinedFunctionError is not a good exception to throw. I only chose it, because it aligns with what Elixir itself does:

Erlang/OTP 27 [erts-15.0] [source] [64-bit] [smp:20:20] [ds:20:20:10] [async-threads:1] [jit:ns]

Interactive Elixir (1.17.0) - press Ctrl+C to exit (type h() ENTER for help)
iex(1)> NonExistingModule.call()
** (UndefinedFunctionError) function NonExistingModule.call/0 is undefined (module NonExistingModule is not available)
    NonExistingModule.call()
    iex:1: (file)
iex(1)> 

I think adding a custom UndefinedModuleError is the most clear thing to do.